When connecting a USB (Universal Serial Bus) device with an isochronous data port to a PC (Personal Computer), the USB device and the PC cannot be placed too far apart from each other. Typically, the USB device plugs into the PC using a cable that is at most a few meters long. In order to place the USB device with the isochronous data port at a greater distance from the PC, there is a device for replacing a USB bus with a network cable or an optical fiber cable, but it is a one-to-one connection, so that it cannot be connected to a network; see Japanese Unexamined Patent Publication No. 2002-542527. There is also a technology that controls the USB device from a network client via the network to a peripheral device server to which the USB device is connected; see the discussion from Silex Technology Inc., owner of the present application, of a USB device server, at:
www dot silex dot jp/japan/products/network/what/index3 dot html (Japanese)
www dot silexamerica dot com/us/products/network/what/index3 dot html (English)
Although this document includes website addresses, the addresses and the material on the sites addressed by the stated addresses are provided only for background. This document does not incorporate by reference any essential material from those websites.
The silex USB device server in question has certain characteristics. As illustrated generally in FIG. 1, a peripheral device driver module transmits an IRP (I/O Request Packet) to a peripheral device server driver module which is preliminarily installed in the network client. The peripheral device server driver module stores the IRP on a queue, and encapsulates a whole or part of the IRP to then pass it to the network. The peripheral device server on a receiving side of the network transmission retrieves transmitted data from the received encapsulated data and reconstructs the data to thereby transmit it to a peripheral device. Response data transmission in the opposite direction is similarly encapsulated and transmitted from the peripheral device via the peripheral device server over the network to the peripheral device server driver module. The peripheral device server driver module retrieves the response data from the received encapsulated data. At this time, the response data is stored in the IRP which has been stored previously, and the IRP is returned to the peripheral device driver, and this queue entry is deleted. As a result of this process, a user can use the peripheral device connected to the peripheral device server as if it is directly connected to the network client.
When the peripheral device with the isochronous data port in the above-mentioned peripheral device is connected to the network client via the network, however, there have been some problems, such as the following. Since the network client and the peripheral device communicate with each other via the network, a request issued by the peripheral device driver is transmitted through the network to the peripheral device, so that it takes time for the response to be transmitted from the peripheral device to the peripheral device driver. Conventionally, when the peripheral device with the isochronous data port is connected to the network client via the peripheral device server, the connection is created on the premise that the peripheral device driver module incorporated in the network client is directly connected to the network client, so that there has been a problem dealing with a delay of the response to the request when the USB peripheral device has been used via the network.
The context of such delay will be described using communication sequence diagrams shown in FIGS. 1 and 2. FIG. 1 shows a communication sequence of the conventional art upon transmitting isochronous data (isochronous OUT). Referring to FIG. 1, a number given to each of the arrows is a frame number provided to each IRP by the peripheral device server driver module. As shown, the peripheral device driver module first issues IRPs corresponding to frames (1), (2), and (3), collectively, sending them to the peripheral device server driver module. The number of the issued IRPs is generally not determined by the peripheral device server driver module, but is determined by external factors, such as a driver incorporated into an operating system of the network client. Subsequently, the peripheral device server driver module which received the issued IRPs encapsulates data included in the IRPs to transmit it over the network to the peripheral device server. At this time, the peripheral device server driver module stores the transmitted IRPs in a queue. The peripheral device server transmits the received data to the peripheral device for the data to be processed on the peripheral device. Upon completion of the data processing, the peripheral device server notifies the peripheral device server driver module that the data processing has been completed, and the peripheral device server driver module which detected this notification will complete the IRPs stored in the queue. A result of completing the IRPs in this way may be that the peripheral device driver module then issues a new IRP. In normal operation, the peripheral device driver module never issues the next IRP until completing the IRPs issued previously. In FIG. 1, the peripheral device server driver module receives from the peripheral device server a frame G(1) indicating that the processing is completed as to frame (1), and the IRP of frame G(1) will be completed. Thereafter, the new IRP frame (4) is issued from the peripheral device driver module. While such a communication method does not pose a problem when the peripheral device is directly connected to the network client, the delay of completion indicated by frame G(1) leads to the delay in issuing the next IRP frame (4) when the USB peripheral device is connected via the network, resulting in the delay of data transmission to the peripheral device.
FIG. 2 illustrates a communication sequence of the conventional art upon receiving the isochronous data (isochronous IN). While the fundamental communication flow is similar to that of the isochronous OUT described above, it is an isochronous IN sequence illustrated in this case, so that the IRP issued from the peripheral device driver module is the request for data and the received data is included in the frames G(1) to G(5). As can be seen in FIG. 2, the frames (4) and (5) which are data requests to the peripheral device are never issued until completing the IRPs of the frames G(1) and G(2), respectively. Also in this case, like the case of the isochronous OUT, the delay in the network leads to the delay of the arrival of the frames G(1) and G(2), which then leads to the delay of the issuance of the next IRPs, frames (4) and (5), resulting finally in the delay of the data in frames G(4) and G(5) that is to be received by the peripheral device driver module.
In addition, since the isochronous data transfer is managed with time in units of a frame of the bus to which the data is transferred, when the peripheral device is directly connected to the network client, it is the network client itself that manages the timing. However, when the peripheral device with the isochronous data port is connected to the peripheral device server, the timing which the peripheral device follows is given from the peripheral device server, even when the isochronous data is ready to be transferred sooner, resulting in the network client and the peripheral device server respectively holding the clocks with different bases therein. For this reason, the time cannot be synchronized per millisecond, so there has been a problem that the timing to manage the isochronous data transfer has been shifted between the network client and the peripheral device server. Such a problem occurs not only in the USB device with the isochronous data transfer but also in the peripheral device, which must manage and process the isochronous data based on the time to be started for use between certain computers.
Other aspects of technology and practice, discussed herein or previously known to those of skill in the art, may also be helpful in understanding the present invention.